[hw,alert_handler,rtl] Use full-scope package definition in toplevel #25935
Conversation
…struct ports Signed-off-by: Robert Schilling <[email protected]>
There was a problem hiding this comment.
This seems fine, but at some point, it sounds like we'll break the stitching tool when we introduce type parameters for some ports.
...or not, if the stitching tool only cared here because the relevant port went up to a "top-level" port. I notice that alert_crashdump_t was left alone.
Hehe, I'm just preparing one PR. Let me check on the |
|
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler.sv This PR doesn't change the functionality of Earlgrey. |
|
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler.sv |
|
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler.sv This won't change behaviour: it's just making some name resolution manual. |
We use a stiching tool to automatically connect ports outside of the OpenTitan bounding box. This tool relies on the fact having the full-scope struct type available in the port list rather than an already imported type. This PR adds the full-scope port type to the alert and escalation interface of the alert handler, which we also use outside of OpenTitan.